Distributed ledger system for insurance record management systems

ABSTRACT

Systems and methods are disclosed with respect to using a distributed ledger, such as a blockchain, for insurance record management systems. The distributed ledger may be utilized to look up information pertaining to a person&#39;s insurance. For example, when a driver is pulled over by law enforcement for speeding, the driver may wish to verify an insurance policy by granting a law enforcement official permission to view his or her insurance records stored on the distributed ledger. Advantageously, the distributed ledger could consequently eliminate the need to carry physical proof of insurance.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present disclosure claims the benefit of (i) U.S. Provisional PatentApplication No. 62/500,049, titled “Distributed Ledger Systems,” filedon May 2, 2017; (ii) U.S. Provisional Patent Application No. 62/500,326,titled “Distributed Ledger System,” filed on May 2, 2017; (iii) U.S.Provisional Patent Application No. 62/508,133, titled “DistributedLedger System for Managing Smart Home Data, Vehicle Data, InsuranceClaim Payouts, and/or Insurance Carrier Discovery,” filed on May 18,2017; (iv) U.S. Provisional Patent Application No. 62,545,262, titled“Distributed Ledger System for Managing Loss Histories,” filed on Aug.22, 2017; (v) U.S. Provisional Patent Application No. 62,548,668, titled“Distributed Ledger System for Managing Vehicle Sensor Data Utilized toDevelop Collision Profiles,” filed on Aug. 22, 2017; (vi) U.S.Provisional Patent Application No. 62,548,679, titled “DistributedLedger System for Use with Vehicle Sensor Data and Usage Based Systems,”filed on Aug. 22, 2017; (vii) U.S. Provisional Patent Application No.62,548,682, titled “Distributed Ledger System for Managing MedicalRecords,” filed on Aug. 22, 2017; (viii) U.S. Provisional PatentApplication No. 62,548,692, titled “Distributed Ledger System forInsurance Record Management Systems,” filed on Aug. 22, 2017; (ix) U.S.Provisional Patent Application No. 62,548,741, titled “DistributedLedger System for Smart Home Data,” filed on Aug. 22, 2017; (x) U.S.Provisional Patent Application No. 62,548,700, titled “DistributedLedger System for Managing Smart Vehicle Data,” filed on Aug. 22, 2017;(xi) U.S. Provisional Patent Application No. 62,548,731, titled“Distributed Ledger System for Claim Payouts,” filed on Aug. 22, 2017;and (xii) U.S. Provisional Patent Application No. 62,548,748, titled“Distributed Ledger System for Carrier Discovery,” filed on Aug. 22,2017; the entire disclosures of which are expressly incorporated hereinby reference.

TECHNICAL FIELD

Systems and methods are disclosed with respect to using a distributedledger for insurance record management systems.

BACKGROUND

Generally speaking, insurance companies may utilize centralizeddatabases or servers for a number of purposes. For example, insurancerecords are generally held by individual insurance companies at acentralized database and are not readily available to third parties whowish, for example, to verify that a person is currently insured.

BRIEF SUMMARY

The present embodiments may detail an individual's insuranceinformation. For instance, a blockchain associated with an individualmay include or link to their past or current insurance policies. As anexample, the blockchain may include data or a block that acts as a proofof auto or homeowners insurance.

In one aspect, a computer-implemented method for managing insurancerecords may include (1) configuring or implementing a plurality ofservers, each of the plurality of servers maintaining a copy of adistributed ledger; (2) creating, at the distributed ledger, a record ofan insurance policy when the insurance policy is created for anindividual; and/or (3) when a request for a verification of insuranceinformation is received, generating the verification by retrieving fromthe distributed ledger all transaction records pertaining to theindividual, and generating a summary of all insurance policiesrepresented by the retrieved transaction records. Creating the record ofthe insurance policy at the distributed ledger may include performingone or more of the following: (i) generating, at a first server from theplurality of servers, a transaction record including data representingthe created policy; (ii) proposing the transaction record to one or moreother servers from the plurality of servers; (iii) performing, via theplurality of servers, a consensus analysis of the transaction recordutilizing a consensus mechanism; and/or (iv) when the consensus analysisindicates that the plurality of servers have formed a consensus, storingthe transaction record at the distributed ledger by storing thetransaction record to each copy of the distributed ledger at theplurality of servers. In one embodiment, the transaction or anotherblock on the blockchain may indicate that an individual has a certaintype of insurance, such as auto insurance, and may act as a proof ofinsurance. The method may include additional, less, or alternateactions, including those discussed elsewhere herein.

Advantages will become more apparent to those of ordinary skill in theart from the following description of the preferred aspects, which havebeen shown and described by way of illustration. As will be realized,the present aspects may be capable of other and different aspects, andtheir details are capable of modification in various respects.Accordingly, the drawings and description are to be regarded asillustrative in nature and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

The figures described below depict various aspects of the system andmethods disclosed herein. It should be understood that each figuredepicts an embodiment of a particular aspect of the disclosed system andmethods, and that each of the figures is intended to accord with apossible embodiment thereof. Further, wherever possible, the followingdescription refers to the reference numerals included in the followingfigures, in which features depicted in multiple figures are designatedwith consistent reference numerals.

There are shown in the drawings arrangements which are presentlydiscussed, it being understood, however, that the present embodimentsare not limited to the precise arrangements and instrumentalities shown,wherein:

FIG. 1A depicts an exemplary database system in accordance with oneaspect of the present disclosure.

FIG. 1B depicts an exemplary distributed ledger system in accordancewith one aspect of the present disclosure.

FIG. 1C depicts an exemplary method for adding a transaction to adistributed ledger in accordance with one aspect of the presentdisclosure.

FIG. 2A depicts an exemplary transaction flow in accordance with oneaspect of the present disclosure.

FIG. 2B depicts an exemplary block propagation flow in accordance withone aspect of the present disclosure.

FIG. 2C depicts an exemplary computer-implemented method for generatinga block in a blockchain in accordance with one aspect of the presentdisclosure.

FIG. 3 depicts an exemplary sequence diagram in accordance with oneaspect of the present disclosure.

FIG. 4 depicts an exemplary node in accordance with one aspect of thepresent disclosure.

FIG. 5 depicts an exemplary blockchain in accordance with one aspect ofthe present disclosure.

FIG. 6A depicts an example computer-implemented method for tracking aloss history utilizing a distributed ledger in accordance with oneaspect of the present disclosure.

FIG. 6B is a block diagram of a client device that may interact with adistributed ledger system in accordance with one aspect of the presentdisclosure.

FIG. 6C is an exemplary loss history report that may be generated by anodes and/or client device in accordance with one aspect of the presentdisclosure.

FIG. 7 depicts, in accordance with one aspect of the present disclosure,an exemplary computer-implemented method for tracking, via a distributedledger, sensor data and other information related to a claim, such as:an estimated damage, an estimated cost of repairs, and/or a paymentstatus for a rental vehicle.

FIG. 8 depicts, in accordance with one aspect of the present disclosure,an exemplary computer-implemented method for managing, via a distributedledger, medical records related to a claim, such as: an injurydescription; one or more medical costs; one or more payout amounts; etc.

FIG. 9 depicts, in accordance with one aspect of the present disclosure,an exemplary computer-implemented method for managing, via a distributedledger, insurance records, such as: a unique identifier for the insured;one or more policy numbers associated with the insured; descriptions ofeach policy for each policy number; coverage amounts; etc.

FIGS. 10-12 and 14 depict exemplary computer-implemented methods ofmaintaining a blockchain associated with insured assets and/orindividuals.

The figures depict aspects of the present embodiments for purposes ofillustration only. One skilled in the art will readily recognize fromthe following discussion that alternate aspects of the structures andmethods illustrated herein may be employed without departing from theprinciples of the invention described herein.

DETAILED DESCRIPTION

The present embodiments relate to, inter alia, systems and methods forusing a distributed ledger to record information related to processesand services in the healthcare, automotive, and real estate industries.For example, a distributed ledger may be used to manage: (i) dataassociated with loss history reports (for either individuals or insuredassets, such as real estate, vehicles, personal articles, etc.); (ii)data associated with sensor-based insurance systems; (iii) dataassociated with medical record systems; and/or (iv) data associated withinsurance record management systems. In some embodiments, thedistributed ledger is a blockchain system. The systems and methodsdescribed herein allow for using a distributed ledger which gives theoption for private information, and permissioned participants in theblockchain. In particular, the systems and methods allow for adistributed consensus amongst businesses, consumers, and authorities, asto the validity of information and transactions stored on thedistributed ledger.

The above listed examples, and disclosed systems and methods, may use anapplication of distributed ledgers, where each new block may becryptographically linked to the previous block in order to form a“blockchain.”

A blockchain is a way of achieving a distributed consensus on thevalidity or invalidity of information. As opposed to using a centralauthority, a blockchain is a distributed database, or ledger, in whichtransactional records are maintained at each node of a peer to peernetwork. Commonly, the distributed ledger is comprised of groupings of“transactional records” (sometimes simply referred to as “transactions”)bundled together into a “block.” Generally speaking, each “transaction”or “transactional record” is a record of an update or change made to thedistributed ledger. The nature of the information included in eachtransactional record generally depends on the particular implementationof a given distributed ledger, and on the information the distributedledger is intended to track.

When a change to the distributed ledger is made (e.g., when a newtransaction and/or block is created), each node must form a consensus asto how the change is integrated into the distributed ledger. Uponconsensus, the agreed upon change is pushed out to each node so thateach node maintains an identical copy of the updated distributed ledger.Any change that does not achieve a consensus is ignored. Accordingly,unlike a traditional system which may use a central authority, a singleparty cannot unilaterally alter the distributed ledger. This inabilityto modify past transactions lead to blockchains being generallydescribed as trusted, secure, and immutable.

Some blockchains may be deployed in an open, decentralized, andpermissionless manner meaning that any party may view information,submit new information, or join the blockchain as a node responsible forconfirming information. This open, decentralized, and permissionlessapproach to a blockchain has limitations. As an example, theseblockchains may not be good candidates for interactions that requireinformation to be kept private, such as information related to a vehiclelifecycle process, or for interactions that require all participants tobe vetted prior to their participation.

In any event, to create a new block, each transaction within a block maybe assigned a hash value (i.e., an output of a cryptographic hashfunction, such as SHA-256 or MD5). These hash values may then becombined together utilizing data storage and cryptographic techniques(e.g., a Merkle Tree) to generate a hash value representative of theentire new block, and consequently the transactions stored in the block.This hash value may then be combined with the hash value of the previousblock to form a hash value included in the header of the new block,thereby cryptographically linking the new block to the blockchain. Tothis end, the precise value utilized in the header of the new block maybe dependent on the hash value for each transaction in the new block, aswell as the hash value for each transaction in every prior block.

According to certain aspects disclosed herein, information stored inblockchains may be trusted, because the hash value generated for the newblock and a nonce value (an arbitrary number used once) are used asinputs into a cryptographic puzzle. The cryptographic puzzle may have adifficulty set by the nodes connected to the blockchain network, or thedifficulty may be set by administrators of the blockchain network. Inone example of the cryptographic puzzle, a solving node uses the hashvalue generated for the new block and repeatedly changes the value ofthe nonce until a solution for the puzzle is found. For example, findingthe solution to the cryptographic puzzle may involve finding the noncevalue that meets certain criteria (e.g., the nonce value begins withfive zeros).

When a solution to the cryptographic puzzle is found, the solving nodepublishes the solution and the other nodes then verify that the solutionis valid. Since the solution depends on the particular hash values foreach transaction within the blockchain, if the solving node attempted tomodify any transaction stored in the blockchain, the solution would notbe verified by the other nodes. More specifically, if a single nodeattempts to modify a prior transaction within the blockchain, a cascadeof different hash values may be generated for each tier of thecryptographic combination technique. This results in the header for oneor more blocks being different than the corresponding header(s) in everyother node that did not make the exact same modification.

Exemplary Database & Distributed Ledger

FIG. 1A depicts an exemplary central authority database system 100 inaccordance with one aspect of the present disclosure. Figure lA includesa central authority 101; a plurality of nodes 103, 105, and 107; acentral ledger 109; and a plurality of network connections 111. In oneexemplary operation of the database system 100, one of the nodes, forexample node 103, issues a request to the central authority 101 toperform an action on data stored in the central ledger 109. This requestmay be a request to create, read, update, or delete data that is storedin the central ledger 109.

In such an example, the central authority 101 receives the request,processes the request, makes any necessary changes to the data stored inthe central ledger 109, and informs the requesting node (node 103) ofthe status of the request. The central authority 101 may also send outstatus updates to the other nodes on the network about the change made,if any, to the data by node 103. In the database system 100, allinteraction with the data stored in the central ledger 109 occursthrough the central authority 101. In this way, the central authorityfunctions as a gatekeeper of the data.

Accordingly, the central authority 101 may operate as a single point ofentry for interacting with the data, and consequently the centralauthority 101 is a single point of failure for the entire databasesystem 100. As such, if the central authority 101 is not accessible tothe nodes in the database system 100, then the data stored in thecentral ledger 109 is not accessible.

In another example, each individual node may keep its own databases andmay periodically send a copy of its database to the central authority101, where the received databases are reconciled to form a singlecohesive record of the data stored in the central ledger 109.

Conversely, FIG. 1B depicts an exemplary distributed ledger system 112in accordance with an aspect of the present disclosure. An example of adistributed ledger system 112 is the blockchain system described above.FIG. 1B includes a plurality of nodes 102, 104, and 106; a distributedledger 114; and a plurality of network connections 110. In thedistributed ledger system 112, each node keeps a copy of the distributedledger 114.

Each copy of the distributed ledger 114 maintains a copy of a pluralityof transactions 116-126 tracked in the distributed ledger 114. Generallyspeaking, each of the transactions 116-126 (sometimes referred to as a“transactional records” or “transaction records”) is a record of anupdate or change made to the distributed ledger 114. The nature of theinformation included in each transactional record 116-126 generallydepends on the particular implementation of the distributed ledger 114,and on the information the distributed ledger 114 is intended to track.

As changes are made to the distributed ledger 114, each node 102-106updates its copy of the distributed ledger 114. A consensus mechanism(sometimes referred to as a consensus protocol) may be used by the nodesin the distributed ledger system 112 to decide when it is appropriate tomake changes to the distributed ledger 114. Example consensus mechanismsthat may be used by the distributed ledger 114 include: proof of work,proof of stake, proof of activity, proof of burn, proof of capacity,and/or proof of elapsed time. Therefore, each node has its own copy ofthe distributed ledger 114, which is identical to every other copy ofthe distributed ledger 114 stored by each other node. The distributedledger system 112 is more robust than a central authority databasesystem such as the system 100 shown in FIG. 1A, because the distributedledger system 112 is decentralized and no single point of failureexists.

The system 112 and distributed ledger 114 may be implemented using anumber of different blockchain protocols, depending on the embodiment.Example blockchain protocols that may be implemented include:Hyperledger Fabric, Ethereum, Corda, Ripple, ZCash, and Sawtooth. Forexample, the method 600 described with reference to FIG. 6A may beimplemented to track loss history using the distributed ledger 114 inone embodiment in which the distributed ledger 114 is configured toutilize the Hyperledger Fabric protocol.

FIG. 1C is a flow chart of an exemplary computer-implemented method 150for adding a transaction to the distributed ledger 114 in accordancewith one aspect of the present disclosure. The method 150 may beimplemented, in whole or in part, by the nodes 102-106 in the system 112shown in FIG. 1B, and may be saved to a memory of one or more of thenodes as one or more instructions or routines executable by a processor.

The method 150 begins when a node proposes a transaction (block 152).The nature of the transaction depends on the implementation. In oneembodiment, the ledger 114 tracks loss history for properties and eachtransaction represents a claim filed against a particular property. Insuch an embodiment, a new transaction might be proposed when aninsurance company receives or completes a claim filed against aparticular property. The transaction might include data about theproperty (e.g., property type, address of a home, make and model of avehicle, etc.), owner (e.g., name, social security number, etc.), and/orclaim (damage type, estimated loss, claim payout amount, etc.).

One or more other nodes in the system 112 may receive the proposedtransaction and attempt to form a consensus in order to verify thevalidity of the transaction (block 154). The nodes may utilize a proofof work consensus protocol such as that already described. If the nodesare unable to reach consensus, the transaction is not added to theledger 114. When the nodes reach consensus, the transaction is added tothe distributed ledger 156. That is, a copy of the transaction is addedto each copy of the ledger 114 held at each node 102-106. Accordingly,the nodes 102-106 are able to maintain identical copies of the ledger114, thus maintaining consistency and accuracy of the ledger 114 withouta single central authority.

Exemplary Transaction Flow & Block Propagation Flow

FIG. 2A depicts an exemplary transaction flow 200 in accordance with oneaspect of the present disclosure. FIG. 2A includes a transactionalrecord (“transaction”) 202; three different time frames 204, 206, and208; the nodes 102-106; the network connections 110; and the distributedledger 114. The transaction flow 200 may represent a sequential flow ofthe transaction 202 through a network (such as the network depicted inFIG. 1B).

In the shown example, the node 102 generates the transaction 202 at time204. The transaction 202 may include data that is stored in thedistributed ledger 114 at the node 102, or may include data received bythe node 102 from outside the distributed ledger 114. The node 102 maytransmit the newly generated transaction 202 to node 106 via the networkconnection 110.

At time 206, the node 106 receives the transaction 202, and confirmsthat the information contained therein is correct. If the informationcontained in the transaction 202 is not correct, the node 106 may rejectthe transaction and not propagate the transaction 202 through thesystem. If the information contained in the transaction 202 is correct,the node 106 may transmit the transaction 202 to the node 104.

At time 208, the node 104 may receive the transaction 202 and mayconfirm or reject the transaction 202. In some embodiments, the node 104may not transmit the confirmed transaction 202, because there are nofurther nodes to transmit to, or all the nodes in the network havealready received transaction 202.

In some embodiments, at any of time frames 204, 206, or 208, any of thenodes may add the confirmed transaction 202 to their copy of thedistributed ledger 114, or to a block of transactions stored in thedistributed ledger 114. In some embodiments, confirming the transaction202 includes checking cryptographic key-pairs for participants involvedin the transaction 202. Checking the cryptographic key-pairs may followa method laid out by a consensus protocol, such as the consensusprotocol discussed in FIG. 1B.

FIG. 2B depicts an exemplary block propagation flow 210 in accordancewith one aspect of the present disclosure. FIG. 2B includes two timeframes 212 and 214; the node 106 and the node 104; the transactions116-122; a set of blocks of transactions 216A-216D; the distributedledger 114; and a blockchain 218. The block propagation flow 210 mayfollow the blockchain system described above, or may follow anotherblockchain propagation algorithm.

The block propagation flow 210 may begin with the node 106 receiving thetransaction 116 at time 212. When node 106 confirms that the transaction116 is valid, the node 106 may add the transaction 116 to the block 216A(which may be newly generated). As part of adding the transaction 116 tothe block 216A, node 106 may solve a cryptographic puzzle and includethe solution in the newly generated block 216A as proof of the work doneto generate the block 216A. This proof of work may be similar to theproof of work described above which utilizes guessing a nonce value. Inother embodiments, the transaction 116 may be added to a pool oftransactions until enough transactions exist to form a block. Node 106may transmit the newly created block 216A to the network at 220. Beforeor after propagating the block 216A, node 106 may add the block 216A toits copy of the blockchain 218.

At time 214, node 104 may receive the block 216A. Node 104 may verifythat the block 216A is valid by checking the solution to thecryptographic puzzle provided in the block 216A. If the solution isaccurate, then the node 104 may add the block 216A to its blockchain 218and transmit the block 216A to the rest of the network at 222.

In one embodiment, one or more transactions 202 or events may relate to:smart contracts, loss history and loss history reports, insuranceclaims, vehicle sensor data, medical records, and/or insurance records.

FIG. 2C depicts an exemplary method 230 for generating the block 216Cshown in FIG. 2B, according to one embodiment. The method 230 may beimplemented by a processor of one or more of the nodes 102-106, and maybe implemented as part of a consensus mechanism. It will be understoodthat the method 230 is exemplary, and not every embodiment implementsthe method 230.

In the method 230, a processor generates hash values 116A-122A for eachof the transactions 116-122, using data associated with each of thetransactions 116-122 as inputs for a hash function (step 232). Theprocessor then generates a hash value 117 using the hash values 116A and118A as inputs for the hash function, and a hash value 121 using thehash values 120A and 122A as inputs for the hash function (step 234).Finally, when generating block 216C, a hash for block 216 is generatedusing as inputs: a hash value of the “chained” block 216B, the hashvales 117 and 121, and a nonce value (step 236). Because every othernode may have access to the block 216B and to the transactions 116-122,when a node publishes that a cryptographic puzzle has been solvedutilizing the nonce value, the other nodes can confirm whether or notthe solution is valid (because a change to any transaction 116-122, orto any transaction in block 216B, or to the nonce value, will result ina different hash value for block 216C).

Exemplary Sequence Diagram

FIG. 3 depicts an exemplary sequence diagram 300 in accordance with oneaspect of the present disclosure. FIG. 3 includes the set of nodes 102,104, and 106. At time 302, the node 102 may generate a transaction. Attime 304, the transaction may be transmitted from the node 102 to thenode 106. At time 306, the node 106 may validate the transaction. Attime 308, if the transaction is valid, the node 106 may transmit thetransaction to node 104. At time 310, node 104 may validate thetransaction. At time 312, the node 106 may compile a block including thevalidated transaction. Compiling a block may include generating asolution to a cryptographic puzzle and linking the block to otherblocks, as described in the embodiments above. At time 314, once theblock is compiled, the node 106 may transmit the block with the solutionto both the node 102 and the node 104.

At time 316, both nodes may validate the solution to the block.Verifying may include checking a cryptographic key-pair as describedabove. At time 318, the three nodes form a consensus that the solutionis valid. Accordingly, in the shown example, all the nodes have formed aconsensus on the blocks of transactions stored by all the nodes.

Exemplary Node

FIG. 4 is a block diagram of the node 102, according to one embodiment.It will be understood that the nodes 104 and 106 may perform one or moreof the functions that the node 102 is capable of performing, and mayinclude one or more of the components included in the node 102. The node102 may utilize the decentralized system 112 described with respect toFIG. 1B, the flows 200 and 210 of transactions and blocks described inFIGS. 2A and 2B, and/or the blockchain system 500 described below withreference to FIG. 5.

The node 102 includes one or more of the following: at least oneprocessor 402, memory 404, a communication module 406, a set ofapplications 408, one or more external ports 410, a user interface 412,a blockchain manager 414, smart contracts 416, an operating system 418,a display screen 420, and input/output components 422. In someembodiments, the node 102 may generate a new block of transactions usingthe blockchain manager 414. Similarly, the node 102 may use theblockchain manager 414 in conjunction with the smart contracts 416stored in memory 404 to execute the functionality disclosed herein.

In some embodiments, the smart contracts 416 operate independent of theblockchain manager 414 or other applications. In some embodiments, thenode 102 does not include one or more of the blockchain manager 414 orthe smart contracts 416. In some embodiments, the node 102 may haveadditional or less components than what is described. The smartcontracts may relate to, or be associated with, insureds and/or insuredassets, including smart insurance contracts, smart maintenancecontracts, smart health care contracts, smart repair or upkeepcontracts, etc.

The node 102, as part of a decentralized ledger system 112, or anotherdecentralized or centralized network, may be used to handle systems thatinteract with and manipulate data and transactions designed for trackingloss history, vehicle sensor data, medical records, and/or insurancerecords.

Exemplary Blockchain System

FIG. 5 depicts an exemplary blockchain system 500 in accordance with anaspect of the present disclosure. The system 500 includes a blockchain502 that includes one or more blocks, including a block of transactions504. The block 504 includes a Merkle Tree 506 that includes one or moretransactions, including a transaction 508 that includes data 510. TheMerkle Tree 506 may be the same Merkle Tree referred to above thatcryptographically links transactions together. In some embodiments, theblockchain system 500 may utilize other methods of organizingtransactions in a block.

As noted, the block of transactions 504 includes the transaction 508,but may also include other transactions in some instances. In someembodiments, the block of transactions 504 has a size limit limiting thenumber of transactions that the block 504 may store. In one exemplaryimplementation, the block 504 includes a reference to a previous blockof transactions that was added to the blockchain 502 prior to the block504 being added to the blockchain 502. As such, and as described above,each block in the blockchain 502 is linked to every other block in theblockchain 502.

In some embodiments, the block of transactions 504 may organize thetransactions it has received into a Merkle Tree 506 to facilitate accessto the stored transactions. The transactions may be hashed using acryptographic hash algorithm, such as the algorithms discussed above,and the hash of each transaction may be stored in the tree. As the treeis constructed, the hash of each adjacent node at the same level ishashed together to create a new node that exists at a higher level inthe tree. Therefore, the root of the tree, or the node at the top of thetree, is dependent upon the hash of each transaction stored below in thetree. Each transaction 508 may include a set of data 510. The set ofdata 510 may include an identifier for the transaction (e.g., a uniquestring), and transaction data identifying the nature of the transactionand what the transactions entails.

In some embodiments, the blockchain 218 shown in FIG. 2B may be similarto the blockchain 502, and the transactions 116-126 shown in FIG. 1B and2B may be similar to the transaction 508. In some embodiments, theledger 114 may share some of the functionality of the system 500, aswell as the organization of blocks and transactions.

Loss History Reports

In one embodiment, a distributed ledger is utilized to track insuranceclaims and to generate loss history reports. The present embodiments maybe configured to track all insurance claims relating to a particularperson and/or property (e.g., a home, automobile, personal articles, orother insured assets), develop one or more loss histories and store themon a blockchain.

In one embodiment, the distributed ledger system 112 shown in FIG. 1Bmay be utilized to track insurance claims. Advantageously, such a systemenables the insurance companies to eliminate the third party typicallyresponsible for maintaining the centralized database. Multiple insurancecompanies may maintain a local copy of the distributed ledger 114. Forexample, Alpha Insurance Company (“Alpha”) may maintain a local copy ofthe ledger 114 at the node 102, Bravo Insurance Company (“Bravo”) maymaintain a local copy of the ledger 114 at the node 104, and CharlieInsurance Company (“Charlie”) may maintain a local copy of the ledger114 at the node 106.

Each transaction stored at the ledger 114 may represent a filed claim,and may include data representing one or more of the following items: aunique transaction identifier; an identifier for the insured (e.g.,unique identifier and/or name of the insured); an address for theinsured; a birth date for the insured; a social security number for theinsured; a name of the insurance company receiving the claim; anindication of the type of insurance policy held by the insured; aninsurance policy number; an identifier for the type of loss (e.g.,indicating fire damage, water damage, hail damage, etc.); the date ofthe loss; the monetary loss for the claim; the status of the claim; andinformation associated with one or more smart contracts, such as a smartinsurance contract.

FIG. 6A depicts an exemplary computer-implemented method 600 fortracking a loss history utilizing a distributed ledger. The method 600may be implemented, in whole or in part, by the system 112 shown in FIG.1B. The method 600 may be saved to a memory as one or more instructionsor routines.

The method 600 begins when someone files a claim with Alpha (block 602).After Alpha receives the claim, the node 102 generates a transactionincluding information pertaining to the claim and proposes thetransaction by transmitting the transaction to nodes 104 and/or 106(block 604). The nodes 102, 104, and 106 then attempt to form aconsensus, using any suitable consensus protocol (such as the hashingand problem solving technique previously described) as to whether thetransaction is valid (block 606). In instances when consensus is notreached, the proposed transaction is not added to the ledger 114 m andnotification that the transaction is invalid may be generated (block608).

When consensus is reached, each of the nodes 102, 104, and 106 adds thetransaction to a block (block 610), and the block, if not already partof the blockchain, is added to the blockchain (block 616) stored at thedistributed ledger 114. Advantageously, after the blockchain has beenupdated, each of the nodes 102, 104, and 106 can access and review thetransaction including the information pertaining to the new claim.Indeed, in one embodiment, any party having access and permission to theblockchain at the ledger 114 may easily generate a report by reviewing,via the ledger 114, all claims associated with a particular property.Consequently, the method 600 eliminates the need for a third partyintermediary that aggregates claim histories from multiple insurancecompany.

FIG. 6B is a block diagram of a client device 650 that may interact withthe system 112 in one embodiment. The client device 650 may include aprocessor 652 and one or more of the following, which may be connectedto the processor 652 via a system bus: a memory 654 including a clientapplication 674, a communication module 656, external ports 660, and auser interface 662. The user interface 662 may include a display screen670 and/or other I/O components 672. The communication module 656 may becommunicatively coupled to the distributed ledger system 112 shown inFIG. 1B, enabling the client device 650 to communicate with one or moreof the nodes 102-106 and to access to the distributed ledger 114.

In example operation, the processor 652 executes the client 674, causingthe client device 650 to communicate with the system 112 via thecommunication module 656. The client device 650 may transmit a requestfor a loss history report pertaining to a particular individual.

The client device 650 may transmit a unique identifier for theindividual. In response, one of the nodes 102-106 responds bytransmitting a report including the pertinent transaction records forall insurance claims for the individual of interest after performing alookup on a local copy of the distributed ledger 114.

In one embodiment, the client device 650 is part of the system 112. Forexample, the memory 654 may include a copy of the distributed ledger 114and/or the blockchain manager 414. In such instances, the client device50 is a node of the system 112, and thus may be considered a serverhosting a copy of the ledger 114. In such an embodiment, when a user ofthe client device 650 requests a loss history report via the userinterface 662, the processor 652 retrieves the pertinent transactionrecords for all insurance claims for the individual of interest from acopy of the distributed ledger 114 stored at the memory 654.

FIG. 6C is an example loss history report 680 that may be generated byone of the nodes 102-106 and/or client device 650 in one embodiment. Thelost history report 680 may be displayed on a display device such as thescreen 670 and/or may be printed. The loss history report 680 may begenerated in response to a request submitted by a user via the userinterface 662 of the client device 650 and transmitted to thedistributed ledger system 112 via the communication module 656.

The loss history report 680 may include: a date of order 681 indicatinga date on which the report 680 was ordered; a date of receipt 682indicating a date on which the report 680 was received; a referencenumber 683 unique to the report 680 (this may be useful if multiplereports are pulled on a single property); a recap 684 identifying anumber of claims reported on the property or person searched; and asearch summary 685. The search summary 685 may identify a person and/orproperty being searched; a person who owns the property being searched;a date of birth for the person; a unique identifier, such as a socialsecurity number, for the person, a sex of the person; and/or a telephonenumber for the person. The property may be a real estate property, suchas a home or office building. In some embodiments, the property ispersonal property, such as a vehicle, jewelry, electronics, paintings,antiques, and/or other personal belongings or insured assets.

The loss history report 680 may list all recent insurance claims filedby an individual or insured, and/or all recent insurance-relatedtransactions associated with the individual or insured.

In other words, the report may be individual-based or individualcentric. The loss history report 680 may additionally or alternativelylist all recent insurance claims filed associated with an insured asset,such as a vehicle or home, and/or all recent insurance-relatedtransactions associated with the insured asset. In other words, thereport may be insurable-asset based or insurable-asset centric.

Sensor-Based Insurance Systems

In one embodiment, a distributed ledger is utilized manage dataassociated with sensor-based insurance systems. While some vehiclesystems collect certain types of sensor data, this sensor data isgenerally locally available to an in-vehicle computer. In someinstances, the sensor data may be uploaded to a centralized server(e.g., maintained by an insurance company for the purpose of monitoringdriving habits).

FIG. 7 depicts an exemplary computer-implemented method 700 fortracking, via a distributed ledger, sensor data and other informationrelated to a claim, such as: an estimated damage, an estimated cost ofrepairs, and/or a payment status for a rental vehicle. The method 700may be implemented, in whole or in part, by the system 112 shown in FIG.1B. The method 700 may be saved to a memory as one or more instructionsor routines.

The method 700 begins when a collision is detected (block 702). Thecollision may be detected from various types of sensor and vehicle data,such as data collected via any of a number of suitable sensors at avehicle, including accelerometers, speedometers, GPS sensors, impactsensors, etc. The sensor and vehicle data may include telematics data(which may include speed, GPS, heading, route, cornering, braking,acceleration, deceleration, and other types of information). The sensorand vehicle data may include mobile device sensor data, which mayinclude some types of telematics data. The sensor and vehicle data mayinclude image, radar, telematics, and other data collected by one ormore smart or autonomous vehicles, such as there may several vehicles inthe vicinity of a vehicle collision at the time of collision, and sensordata from the several vehicles may be collected, and analyzed.

After detecting the collision, the node 102 (which may be a computerinstalled in the vehicle or a mobile device such as a tablet or smartphone, depending on the embodiment) generates a transaction includingsensor data pertaining to the collision. In a manner similar to thatdescribed with reference to blocks 604-616, the transaction is proposed,the nodes attempt to reach consensus, and the transaction is added tothe ledger 114 when consensus is reached (blocks 704-716).

Advantageously, after the ledger 114 has been updated, each of the nodes102, 104, and 106 can access and review the transaction including thesensor data and associated information pertaining to a claim. One ormore systems may access the ledger 114 to estimate damage and/or cost ofrepairs based upon the sensor data, and may similarly update the ledger114 to include this information. Notably, the method 700 gives a useraccess to data relating to his or her collision; he or she may not haveto interact with a gatekeeper responsible for maintaining information ata centralized database.

In another example, one or more home-based “smart devices,” claimassessment drones, and/or an insurance company may utilize the ledger114 to track information related to a real estate claim, such as:estimated damage to a home, estimated repair costs, payouts associatedwith the claim, third parties to be receive payouts, etc.

In yet another example, one or more vehicles and an insurance companymay utilize the ledger 114 to track sensor data for the purpose ofupdating a UBI profile. Such an example similarly offers a user theadvantage of having access to his or her data that might otherwise bestored at a centralized database.

Medical Record Systems

In one embodiment, a distributed ledger is utilized manage medicalrecord systems. Currently, medical records are often held by a multitudeof different institutions, each of which maintains its own centralizeddatabase including an incomplete record of a patient's medical history(e.g., relating to only a certain period of time or to certain specialtyprocedures). By contrast, the disclosed system enables aggregation of acomplete medical history (to the extent desired), and gives a patientaccess to records of his or her medical records. In particular, thedisclosed system may be utilized to track medical records associatedwith particular insurance claims.

FIG. 8 depicts an example method 800 for managing, via a distributedledger, medical records related to a claim, such as: an injurydescription; one or more medical costs; one or more payout amounts; etc.The method 800 may be implemented, in whole or in part, by the system112 shown in FIG. 1B. The method 800 may be saved to a memory as one ormore instructions or routines.

The method 800 begins when a claim is filed (e.g., after a vehiclecollision) (block 802). After the claim is received, the node 102generates a transaction including data pertaining to the claim, and moreparticularly, to medical records associated with an injury resultingfrom the event that led to the claim. In a manner similar to thatdescribed with reference to blocks 604-616, the transaction is proposed,the nodes attempt to reach consensus, and the transaction is added tothe ledger 114 when consensus is reached (blocks 804-816).

One or more systems may access the ledger 114 to facilitate processing aclaim associated with the transaction. Further, the method 800 gives apatient and/or an insurance company (when permitted) access to his orher medical records, which typically is maintained at a centralizeddatabase at a health care institution or at a service providerassociated with the health care institution.

Insurance Record Management Systems

In one embodiment, a distributed ledger may be utilized to manageinsurance record management systems. Currently, insurance records aregenerally held by individual insurance companies and are not readilyavailable to third parties who wish, for example, to verify that aperson is currently insured. By contrast, the disclosed system maymanage insurance records via a distributed ledger, enabling multipleparties to easily verify a person's insurance policy.

FIG. 9 depicts an exemplary computer-implemented method 900 formanaging, via a distributed ledger, insurance records, such as: a uniqueidentifier for the insured; one or more policy numbers associated withthe insured; descriptions of each policy for each policy number;coverage amounts; etc. The method 900 may be implemented, in whole or inpart, by the system 112 shown in FIG. 1B. The method 900 may be saved toa memory as one or more instructions or routines.

The method 900 may begin when an insurance policy is generated forsomeone (block 902). The generated policy could be for any suitableinsurance product, such as home insurance, vehicle insurance, umbrellainsurance, life insurance, etc. After the policy is generated, the node102 generates a transaction including data pertaining to the policy. Ina manner similar to that described with reference to blocks 604-616, thetransaction is proposed, the nodes attempt to reach consensus, and thetransaction is added to the ledger 114 when consensus is reached (blocks904-916).

One or more systems may access the ledger 114 to lookup informationpertaining to someone's insurance. For example, when a driver is pulledover by law enforcement for speeding, he or she may wish to verify hisinsurance policy by granting a law enforcement official permission toview his or her insurance records stored on the ledger 114.Advantageously, the method 900 could consequently eliminate the need tocarry physical proof of insurance. Further, the method 900 could beutilized to make the exchange of insurance information after an accidentmore efficient.

Additional Exemplary Loss History

In the insurance industry, loss history may have several meanings. Losshistory may include or comprise a report detailing information or datafrom multiple insurers about an individual's insurance claim history andother asset/insured related information. For instance, loss history maydetail the insurance claims filed or reported by an insured, orinsurance claims filed relating to an insured asset, such as anautomobile or home.

Insurance provider remote servers may report their data to a private orpublic blockchain, and then the blockchain may generate a consumer'shistory report independently of 3rd party data aggregators. Forinstance, the blockchain may include up-to-date information about aninsured vehicle, an insured home, other insured assets, and/or aboutindividual customers. The information maintained on the block mayinclude insurance claim information, including amount of claim, andvarious types of sensor information (telematics, smart vehicle, mobiledevice, smart home, smart infrastructure, and other sensor data).

Insurance provider remote servers may submit information to theblockchain on real-time or periodic basis. In one embodiment, insurancecompanies may request data by forwarding search criteria such as aninsurance applicant's name, date of birth, risk address, social securitynumbers (SSNs), etc. An electronic search tool or engine may search ashared ledger for information that matches the requested search criteriaand delivers results of the search.

In one aspect, the blockchain may act as an event registry that updatesinformation on the blockchain each time there is an event. For instance,a vehicle-based blockchain may update information each time there is newinformation, or a change in information, related to the vehicle owner,the insured, or the vehicle, including change of addresses, newinsurance claims, vehicle maintenance/repair events, etc. As anotherexample, a home-based blockchain update information on the chain eachtime there is new information, or a change in information, related tothe home or the homeowner (or the insured), including payment of taxesand/or insurance, and/or new insurance claims and homerepairs/maintenance.

Exemplary Methods of Maintaining a Blockchain

FIG. 10 depicts an exemplary computer-implemented method of maintaininga blockchain on insured assets or individuals 1000. The method 1000 mayinclude, via one or more local or remote processors, sensors, servers,and/or transceivers, (1) receiving a notification of, or associatedwith, a change in information associated with an insured and/or aninsured vehicle, insured home, insured personal articles, and/or otherinsured assets 1002; and/or (2) receiving a notification of, orassociated with, a loss associated with an insured, or an insuredvehicle, insured home, insured personal articles, and/or other insuredassets 1004. The notification of loss may include loss information,claim information, various sensor data, telematics data, autonomousvehicle sensor or other data, intelligent home sensor or other data,mobile device data, and/or other data about insureds and insured assets,including that discussed elsewhere herein). For instance, thenotifications may be received via wireless communication or datatransmission over one or more radio frequency links or digitalcommunication channels, and stored in a local memory.

The method 1000 may include, via one or more local or remote processors,sensors, servers, and/or transceivers, (3) identifying and/or accessinga blockchain using an identifier associated with both the blockchain andan insured and/or insured asset 1006. For instance, a VIN (VehicleIdentification Number) may be used to identify and/or access an insuredvehicle and an associated blockchain. A SSN may be used to identifyand/or access an insured and an associated blockchain. An address, MLSlisting, or tax parcel number may be used to identify and/or access aninsured home and an associated blockchain. In some embodiments, theidentifiers may hashed and/or encrypted, along with other data and/orblocks within the blockchain.

The method 1000 may include, via one or more local or remote processors,sensors, servers, and/or transceivers, (4) creating a new block usingthe new information (or changed information) and/or the notification ofloss information, and/or an amount of loss and other loss information1008. The method 1000 may include, via one or more local or remoteprocessors, sensors, servers, and/or transceivers, (5) transmitting thenew block to a network of nodes to form a consensus among the nodes aswhether or not to update the blockchain 1010. For instance, the newblock may be transmitted to other nodes within a network via wirelesscommunication or data transmission over one or more radio links.

The method 1000 may include, via one or more local or remote processors,sensors, servers, and/or transceivers, (6) receiving or determining whena consensus is formed from communicating with other nodes in thenetworks 1012. When a consensus if formed, the method 1000 may include,via one or more local or remote processors, sensors, servers, and/ortransceivers, (7) updating the blockchain, on each node, with the newblock 1014, and (8) handling or updating an insurance claim for aninsured asset, and/or facilitating repairs for an insured asset 1016 ifnot yet performed or still necessary. The method may include additional,less, or alternate actions, including those discussed elsewhere herein,and/or may be carried out by computer systems comprising of one or moreprocessors, servers, sensors, and/or transceivers configured to performthe functionality and/or via computer-executable instructions stored oncomputer readable medium or media.

FIG. 11 depicts another exemplary computer-implemented method ofmaintaining a blockchain associated with insured assets and/orindividuals 1100. The method 1100 may include, via one or more local orremote processors, sensors, servers, and/or transceivers, (1) receivinga notification of, or associated with, a change in informationassociated with an insured and/or an insured vehicle, insured home,insured personal articles, and/or other insured assets 1102; and/or (2)receiving a notification of, or associated with, a loss associated withan insured, or an insured vehicle, insured home, insured personalarticles, and/or other insured assets 1104. The notification of loss mayinclude loss information, claim information, various sensor data,telematics data, autonomous vehicle sensor or other data, intelligenthome sensor or other data, mobile device data, and/or other data aboutinsureds and insured assets, including that discussed elsewhere herein).For instance, the notifications may be received via wirelesscommunication or data transmission over one or more radio frequencylinks or digital communication channels, and stored in a local memory.

The method 1100 may include, via one or more local or remote processors,sensors, servers, and/or transceivers, (3) identifying and/or accessinga blockchain using an identifier associated with both the blockchain andan insured and/or insured asset 1106. For instance, a VIN (VehicleIdentification Number) may be used to identify and/or access an insuredvehicle and an associated blockchain. A SSN may be used to identifyand/or access an insured and an associated blockchain. An address, MLSlisting, or tax parcel number may be used to identify and/or access aninsured home and an associated blockchain. In some embodiments, theidentifiers may hashed and/or encrypted, along with other data and/orblocks within the blockchain.

The method 1100 may include, via one or more local or remote processors,sensors, servers, and/or transceivers, (4) receiving or retrieving froma memory new information associated with a change in information and/ora notification of loss (and/or amount and type of loss) 1408. The method1100 may include, via one or more local or remote processors, sensors,servers, and/or transceivers, (5) transmitting the new information to anetwork of nodes to form a consensus among the nodes as whether or notto update the blockchain 1110. For instance, the new block may betransmitted to other nodes within a network via wireless communicationor data transmission over one or more radio links.

The method 1100 may include, via one or more local or remote processors,sensors, servers, and/or transceivers, (6) receiving or determining whena consensus is formed from communicating with other nodes in thenetworks 1112. When a consensus if formed, the method 1100 may include,via one or more local or remote processors, sensors, servers, and/ortransceivers, (7) creating a new block using the new information (orchanged information) and/or the notification of loss information, and/oran amount of loss and other loss information 1114, and (8) updating theblockchain, on each node, with the new block 1116, or otherwise updatingthe blockchain on each node with the new information. The method 1100may also include, via one or more local or remote processors, sensors,servers, and/or transceivers, (9) handling or updating an insuranceclaim for an insured asset, and/or facilitating repairs for an insuredasset 1118 if not yet performed or still necessary. The method mayinclude additional, less, or alternate actions, including that discussedelsewhere herein, and/or may be carried out by computer systemscomprising of one or more processors, servers, sensors, and/ortransceivers configured to perform the functionality and/or viacomputer-executable instructions stored on computer readable medium ormedia.

FIG. 12 depicts another exemplary computer-implemented method ofmaintaining a blockchain associated with insured assets and/orindividuals 1200. The method 1200 may include, via one or more local orremote processors, sensors, servers, and/or transceivers, (1) receivinga notification of, or associated with, a change in informationassociated with an insured and/or an insured vehicle, insured home,insured personal articles, and/or other insured assets 1202, such asfrom a node associated with an insurance provider or from an insuranceprovider remote server. For instance, the notifications may be receivedvia wireless communication or data transmission over one or more radiofrequency links or digital communication channels, and stored in a localmemory.

The method 1200 may include, via one or more local or remote processors,sensors, servers, and/or transceivers, (2) identifying and/or accessinga blockchain using an identifier associated with both the blockchain andan insured and/or insured asset 1204. For instance, a VIN (VehicleIdentification Number) may be used to identify and/or access an insuredvehicle and an associated blockchain. A SSN may be used to identifyand/or access an insured and an associated blockchain. An address, MLSlisting, or tax parcel number may be used to identify and/or access aninsured home and an associated blockchain. In some embodiments, theidentifiers may hashed and/or encrypted, along with other data and/orblocks within the blockchain.

The method 1200 may include, via one or more local or remote processors,sensors, servers, and/or transceivers, (3) receiving or retrieving froma memory new information associated with a change in information and/ora change in carrier (or otherwise a new carrier) 1506. The method 1200may include, via one or more local or remote processors, sensors,servers, and/or transceivers, (4) transmitting the new information (suchas identification of a new carrier and/or new policy information) to anetwork of nodes to form a consensus among the nodes as whether or notto update the blockchain 1208. For instance, the new block may betransmitted to other nodes within a network via wireless communicationor data transmission over one or more radio links.

The method 1200 may include, via one or more local or remote processors,sensors, servers, and/or transceivers, (5) receiving or determining whena consensus is formed from communicating with other nodes in thenetworks 1210. When a consensus if formed, the method 1200 may include,via one or more local or remote processors, sensors, servers, and/ortransceivers, (6) creating a new block using the new information (orchanged information) and/or the new insurance carrier and/or newinsurance policy information 1212, and/or (7) updating the blockchain,on each node, with the new block 1214, or otherwise updating theblockchain on each node with the new information. The method 1200 mayalso include handling or updating an insurance claim for an insuredasset, and/or facilitating repairs for an insured asset if not yetperformed or still necessary. The method may include additional, less,or alternate actions, including that discussed elsewhere herein, and/ormay be carried out by computer systems comprising of one or moreprocessors, servers, sensors, and/or transceivers configured to performthe functionality and/or via computer-executable instructions stored oncomputer readable medium or media.

FIG. 14 depicts another exemplary computer-implemented method ofmaintaining a blockchain on insured assets or individuals 1400. Themethod 1400 may include, via one or more local or remote processors,sensors, servers, and/or transceivers, (1) receiving a notification of,or associated with, an insurance claim associated with an insured and/oran insured vehicle, insured home, insured personal articles, and/orother insured assets, and/or receiving insurance claim related data1402, such as from a node associated with an insurance provider or froman insurance provider remote server. For instance, the notifications maybe received via wireless communication or data transmission over one ormore radio frequency links or digital communication channels, and storedin a local memory.

The method 1400 may include, via one or more local or remote processors,sensors, servers, and/or transceivers, (2) identifying and/or accessinga blockchain using an identifier associated with both the blockchain andan insured and/or insured asset 1404. For instance, a VIN (VehicleIdentification Number) may be used to identify and/or access an insuredvehicle and an associated blockchain. A SSN may be used to identifyand/or access an insured and an associated blockchain. An address, MLSlisting, or tax parcel number may be used to identify and/or access aninsured home and an associated blockchain. In some embodiments, theidentifiers may hashed and/or encrypted, along with other data and/orblocks within the blockchain.

The method 1400 may include, via one or more local or remote processors,sensors, servers, and/or transceivers, (3) receiving or retrieving froma memory new information associated with an insurance claim and/or anamount associated with an insurance claim 1406. The method 1400 mayinclude, via one or more local or remote processors, sensors, servers,and/or transceivers, (4) transmitting the new information (such asidentification of a new insurance claim and policy information) to anetwork of nodes to form a consensus among the nodes as whether or notto update the blockchain 1408. For instance, the new block may betransmitted to other nodes within a network via wireless communicationor data transmission over one or more radio links.

The method 1400 may include, via one or more local or remote processors,sensors, servers, and/or transceivers, (5) receiving or determining whena consensus is formed from communicating with other nodes in thenetworks 1410. When a consensus if formed, the method 1400 may include,via one or more local or remote processors, sensors, servers, and/ortransceivers, (6) creating a new block using the new insurance claimdata and/or policy data 1412, and/or (7) updating the blockchain, oneach node, with the new block 1414, or otherwise updating the blockchainon each node with the new insurance claim information. The method 1400may also include handling or updating an insurance claim for an insuredasset, and/or facilitating repairs for an insured asset if not yetperformed or still necessary. The method may include additional, less,or alternate actions, including that discussed elsewhere herein, and/ormay be carried out by computer systems comprising of one or moreprocessors, servers, sensors, and/or transceivers configured to performthe functionality and/or via computer-executable instructions stored oncomputer readable medium or media.

In one exemplary flow, a computer-implemented method may include (1)receiving, at a processor coupled with a network interface (such as viawireless communication or data transmission over one or more radiolinks), an insurance claim notification from at least a firstparticipant, wherein the claim notification comprises an insured assetidentifier, and an insured asset owner identifier; (2) retrieving oraccessing, at a memory coupled with a processor, the blockchain usingthe insured asset identifier and/or insured asset owner identifier. Themethod may include (3) updating, at the memory, a block stored at thememory using the insured asset identifier and/or insured asset owneridentifier; and (4) transmitting, via the processor coupled with thenetwork interface (such as via wireless communication or datatransmission over one or more radio links), the block to at least asecond participant or node within a private or public communicationnetwork.

In some embodiments, insured asset may be a vehicle, a home, or apersonal article. The first participant or node may be a sensor, asensor system, or computer system attached to the insured asset, such asan autonomous vehicle technology system mounted on a vehicle. In otherembodiments, the first participant or node may be a repair shop serveror computer system. Similarly, in some embodiments, accessing theblockchain using the insured asset identifier or the insured identifiedmay include searching, at the processor, the blockchain using theinsured asset identifier or insured identifier for a block or blockchainthat includes the insured asset identifier or insured identifier; andverifying, at the processor, the insured asset identifier or insuredidentifier stored at the block.

In other embodiments, if the insured asset identifier is not stored at ablock, the method may include generating, at the processor, an insuredasset record using the insured asset identifier; adding, at theprocessor, the insured asset identifier and the insured identifier to aninsured asset transaction; adding, at the processor, the insured assettransaction to a set of insured asset loss or other transactions; andadding, at the processor, the set of insured asset loss or othertransactions to the block.

In other embodiments, the method may include solving, at the processor,a cryptographic puzzle corresponding to the block; and adding, at theprocessor, the solution to the cryptographic puzzle to the block.Additionally, in some embodiments, updating, at the memory, theblockchain by adding the block to the blockchain.

In yet other embodiments of the method, the at least one otherparticipant is an insurer, a vehicle owner, a repair shop, orcombinations thereof. In some embodiments, the method may includereceiving, at the processor, a repair notification from one or moreremote servers associated with other parties, such as repair shops orpart suppliers.

The blockchains discussed herein may be updated after one or moretriggering events are detected. For instance, the triggering events mayinclude change of ownership, passage of time (e.g., every week, month, 3months, or 6 months), amount of miles put on a vehicle (e.g., 5,000 or10,000 miles), an amount of time the vehicle has driven, or operated ifautonomous, vehicle or home maintenance being performed or not beingperformed, change of address, change in tax or insurance status, changein lender, change in insurance carrier, etc.

EXEMPLARY ASPECTS

Embodiments of the techniques described in the present disclosure mayinclude any number of the following aspects, either alone orcombination. In one aspect, a computer-implemented method for managinginsurance records for policies for individuals may be provided. Themethod may include configuring or implementing a plurality of servers,each of the plurality of servers maintaining a copy of a distributedledger; performing the following when an insurance policy is created foran individual: (i) generating, at a first server from the plurality ofservers, a transaction record including data representing the createdpolicy; (ii) proposing the transaction record to one or more otherservers from the plurality of servers; (iii) performing, via theplurality of servers, a consensus analysis of the transaction recordutilizing a consensus mechanism; and/or (iv) when the consensus analysisindicates that the plurality of servers have formed a consensus, storingthe transaction record at the distributed ledger by storing thetransaction record to each copy of the distributed ledger at theplurality of servers; and when a request for a verification of insuranceinformation is received, generating the verification by retrieving fromthe distributed ledger all transaction records pertaining to theindividual, including the proposed transaction, and generating a summaryof all insurance policies represented by the retrieved transactionrecords. The method may include additional, less, or alternatefunctionality, including that discussed elsewhere herein.

For instance, storing the transaction record at the distributed ledgermay include storing the transaction to a block. Performing the consensusanalysis may include generating a hash value for the transaction, andutilizing the hash value for the transaction to generate a hash valuefor the block. The consensus mechanism may be: a proof of workmechanism, a proof of stake mechanism, or a proof of activity mechanism.Additionally or alternatively, the consensus mechanism may be: a proofof burn mechanism, a proof of capacity mechanism, or a proof of elapsedtime mechanism.

The transaction record may include data representing: an identity of theindividual, a policy number for each insurance policy held by theindividual, and a coverage amount for each insurance policy held by theindividual. The method may include verifying that a requestor thatsubmitted the request for the verification is authorized, wherein theverification is only generated when requestor is authorized.

The method may include receiving from the individual a list ofauthorized parties; wherein verifying that the requestor is authorizedincludes verifying that the requestor is on the list of authorizedparties. The method may also include receiving from an insurance companya list of authorized parties; wherein verifying that the requestor isauthorized includes verifying that the requestor is on the list ofauthorized parties. The method may include generating a notificationthat the individual has no insurance records when the distributed ledgerincludes no transaction records pertaining to the individual.

In another aspect, a computer system for managing insurance records fora policies for individuals may be provided. The system may include aplurality of servers maintaining a distributed ledger for managinginsurance records, wherein each of the plurality of servers may includea memory storing: (A) a copy of the distributed ledger, and (B)instructions that, when executed, cause the respective server to: (i)generate, at the respective server, a transaction record including datarepresenting a created insurance policy for an individual; wherein theplurality of servers are configured to: (i) perform a consensus analysisof the proposed transaction record utilizing a consensus mechanism; (ii)store the transaction record at the distributed ledger when theconsensus analysis indicates that the plurality of servers have formed aconsensus by storing the transaction record to each copy of thedistributed ledger at the plurality of servers; and/or (iii) generate averification of insurance information for the individual in response toreceiving a request by retrieving from a copy of the distributed ledgerall transaction records, including the proposed transaction record, andgenerating a summary of all insurance policies represented by theretrieved transaction records. The system may be include additional,less, or alternate functionality, including that discussed elsewhereherein.

In another aspect, a computer-implemented method for managing insurancerecords for an insured asset may be provided. The method may include:configuring or implementing a plurality of servers, each of theplurality of servers maintaining, or configured to maintain, a copy of adistributed ledger; performing the following when an insurance policy iscreated for an insured asset: (i) generating, at a first server from theplurality of servers, a transaction record including data representingthe created policy; (ii) proposing the transaction record to one or moreother servers from the plurality of servers; (iii) performing, via theplurality of servers, a consensus analysis of the transaction recordutilizing a consensus mechanism; and/or (iv) when the consensus analysisindicates that the plurality of servers have formed a consensus, storingthe transaction record at the distributed ledger by storing thetransaction record to each copy of the distributed ledger at theplurality of servers; and when a request for a verification of insuranceinformation is received, generating the verification by retrieving fromthe distributed ledger all transaction records pertaining to the insuredasset, including the proposed transaction, and generating a summary ofall insurance policies represented by the retrieved transaction records.Storing the transaction record at the distributed ledger may includestoring the transaction to a block, and the transaction may pertain to asmart contract associated with the insured asset. The transaction recordmay include data representing: information describing the insured asset,an identity of the insured, a policy number for each insurance policyheld by the insured and/or covering the insured asset, and a coverageamount for each insurance policy. The method may include additional,less, or alternate actions, including those discussed elsewhere herein.

For instance, the method may include verifying that a requestor thatsubmitted the request for the verification is authorized, wherein theverification is only generated when the requestor is authorized. Themethod may include receiving from the individual a list of authorizedparties; wherein verifying that the requestor is authorized includesverifying that the requestor is on the list of authorized parties. Themethod may include receiving from an insurance company a list ofauthorized parties; wherein verifying that the requestor is authorizedincludes verifying that the requestor is on the list of authorizedparties. The method may include generating a notification that theinsured asset has no insurance records when the distributed ledgerincludes no transaction records pertaining to the insured asset.

Additional Considerations

With the foregoing, an insurance customer may opt-in to a rewards,insurance discount, or other type of program (such as the UBI programdescribed with reference to FIG. 7). After the insurance customerprovides their affirmative consent, an insurance provider remote servermay collect data from the customer's mobile device, smart or autonomousvehicle, smart home controller, or other smart devices. The datacollected may be related to smart home functionality (or home occupantpreferences or preference profiles), smart or autonomous vehiclefunctionality, and/or insured assets before (and/or after) aninsurance-related event, including those events discussed elsewhereherein. In return, risk averse insureds, home or vehicle owners, orhome, vehicle, or apartment occupants may receive discounts or insurancecost savings related to home, renters, personal articles, auto,mobility, and other types of insurance from the insurance provider.

In one aspect, telematics data, smart or autonomous vehicle data, mobiledevice data, smart or interconnected home data, and/or other data,including the types of data discussed elsewhere herein, may be collectedor received by an insurance provider remote server (e.g., via direct orindirect wireless communication or data transmission from a smart homecontroller, mobile device, or other customer computing device) after acustomer affirmatively consents or otherwise opts-in to an insurancediscount, reward, or other program. The insurance provider may thenanalyze the data received with the customer's permission to providebenefits to the customer. As a result, risk averse customers may receiveinsurance discounts or other insurance cost savings based upon data thatreflects low risk behavior and/or technology that mitigates or preventsrisk to (i) insured assets, such as homes, personal belongings, orvehicles, and/or (ii) individuals.

This detailed description is to be construed as exemplary only and doesnot describe every possible embodiment, as describing every possibleembodiment would be impractical, if not impossible. One may be implementnumerous alternate embodiments, using either current technology ortechnology developed after the filing date of this application.

Further to this point, although the embodiments described herein oftenutilize credit report information as an example of sensitiveinformation, the embodiments described herein are not limited to suchexamples. Instead, the embodiments described herein may be implementedin any suitable environment in which it is desirable to identify andcontrol specific type of information. As part of implementing theautomotive claims process, vehicle loss history, and the lifecycle of aVehicle Identification Number, a financial institution may be a part ofthe process. For example, the aforementioned embodiments may beimplemented by the financial institution to identify and contain bankaccount statements, brokerage account statements, tax documents, etc. Toprovide another example, the aforementioned embodiments may beimplemented by a lender to not only identify, re-route, and quarantinecredit report information, but to apply similar techniques to preventthe dissemination of loan application documents that are preferablydelivered to a client for signature in accordance with a more securemeans (e.g., via a secure login to a web server) than via email.

With the foregoing, a user may be an insurance customer who may opt-into a rewards, insurance discount, or other type of program. After theinsurance customer provides their affirmative consent, an insuranceprovider remote server may collect data from the customer's mobiledevice, smart home controller, smart vehicle, autonomous vehicle, orother smart devices—such as with the customer's permission oraffirmative consent. The data collected may be related to smart vehicleor smart home functionality (or home occupant preferences or preferenceprofiles), and/or insured assets before (and/or after) aninsurance-related event, including those events discussed elsewhereherein. In return, risk averse insureds, home or vehicle owners,passengers or drivers may receive discounts or insurance cost savingsrelated to home, renters, personal articles, auto, life, health,mobility, and other types of insurance from the insurance provider.

Furthermore, although the present disclosure sets forth a detaileddescription of numerous different embodiments, it should be understoodthat the legal scope of the description is defined by the words of theclaims set forth at the end of this patent and equivalents. The detaileddescription is to be construed as exemplary only and does not describeevery possible embodiment since describing every possible embodimentwould be impractical. Numerous alternative embodiments may beimplemented, using either current technology or technology developedafter the filing date of this patent, which would still fall within thescope of the claims. Although the following text sets forth a detaileddescription of numerous different embodiments, it should be understoodthat the legal scope of the description is defined by the words of theclaims set forth at the end of this patent and equivalents. The detaileddescription is to be construed as exemplary only and does not describeevery possible embodiment since describing every possible embodimentwould be impractical. Numerous alternative embodiments may beimplemented, using either current technology or technology developedafter the filing date of this patent, which would still fall within thescope of the claims.

Throughout this specification, plural instances may implementcomponents, operations, or structures described as a single instance.Although individual operations of one or more methods are illustratedand described as separate operations, one or more of the individualoperations may be performed concurrently, and nothing requires that theoperations be performed in the order illustrated. Structures andfunctionality presented as separate components in example configurationsmay be implemented as a combined structure or component. Similarly,structures and functionality presented as a single component may beimplemented as separate components. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter herein.

Additionally, certain embodiments are described herein as includinglogic or a number of routines, subroutines, applications, orinstructions. These may constitute either software (e.g., code embodiedon a machine-readable medium or in a transmission signal) or hardware.In hardware, the routines, etc., are tangible units capable ofperforming certain operations and may be configured or arranged in acertain manner. In exemplary embodiments, one or more computer systems(e.g., a standalone, client or server computer system) or one or morehardware modules of a computer system (e.g., a processor or a group ofprocessors) may be configured by software (e.g., an application orapplication portion) as a hardware module that operates to performcertain operations as described herein.

In various embodiments, a hardware module may be implementedmechanically or electronically. For example, a hardware module maycomprise dedicated circuitry or logic that is permanently configured(e.g., as a special-purpose processor, such as a field programmable gatearray (FPGA) or an application-specific integrated circuit (ASIC)) toperform certain operations. A hardware module may also compriseprogrammable logic or circuitry (e.g., as encompassed within ageneral-purpose processor or other programmable processor) that istemporarily configured by software to perform certain operations. Itwill be appreciated that the decision to implement a hardware modulemechanically, in dedicated and permanently configured circuitry, or intemporarily configured circuitry (e.g., configured by software) may bedriven by cost and time considerations.

Accordingly, the term “hardware module” should be understood toencompass a tangible entity, be that an entity that is physicallyconstructed, permanently configured (e.g., hardwired), or temporarilyconfigured (e.g., programmed) to operate in a certain manner or toperform certain operations described herein. Considering embodiments inwhich hardware modules are temporarily configured (e.g., programmed),each of the hardware modules need not be configured or instantiated atany one instance in time. For example, where the hardware modulescomprise a general-purpose processor configured using software, thegeneral-purpose processor may be configured as respective differenthardware modules at different times. Software may accordingly configurea processor, for example, to constitute a particular hardware module atone instance of time and to constitute a different hardware module at adifferent instance of time.

Hardware modules may provide information to, and receive informationfrom, other hardware modules. Accordingly, the described hardwaremodules may be regarded as being communicatively coupled. Where multipleof such hardware modules exist contemporaneously, communications may beachieved through signal transmission (e.g., over appropriate circuitsand buses) that connect the hardware modules. In embodiments in whichmultiple hardware modules are configured or instantiated at differenttimes, communications between such hardware modules may be achieved, forexample, through the storage and retrieval of information in memorystructures to which the multiple hardware modules have access. Forexample, one hardware module may perform an operation and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further hardware module may then, at a latertime, access the memory device to retrieve and process the storedoutput. Hardware modules may also initiate communications with input oroutput devices, and may operate on a resource (e.g., a collection ofinformation).

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods or routines described herein may be at leastpartially processor-implemented. For example, at least some of theoperations of a method may be performed by one or more processors orprocessor-implemented hardware modules. The performance of certain ofthe operations may be distributed among the one or more processors, notonly residing within a single machine, but deployed across a number ofmachines. In some example embodiments, the processor or processors maybe located in a single location (e.g., within a home environment, anoffice environment or as a server farm), while in other embodiments theprocessors may be distributed across a number of locations.

The performance of certain of the operations may be distributed amongthe one or more processors, not only residing within a single machine,but deployed across a number of machines. In some example embodiments,the one or more processors or processor-implemented modules may belocated in a single geographic location (e.g., within a homeenvironment, an office environment, or a server farm). In other exampleembodiments, the one or more processors or processor-implemented modulesmay be distributed across a number of geographic locations.

Unless specifically stated otherwise, discussions herein using wordssuch as “processing,” “computing,” “calculating,” “determining,”“presenting,” “displaying,” or the like may refer to actions orprocesses of a machine (e.g., a computer) that manipulates or transformsdata represented as physical (e.g., electronic, magnetic, or optical)quantities within one or more memories (e.g., volatile memory,non-volatile memory, or a combination thereof), registers, or othermachine components that receive, store, transmit, or displayinformation.

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment is included in at least oneembodiment. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment.

Some embodiments may be described using the expression “coupled” and“connected” along with their derivatives. For example, some embodimentsmay be described using the term “coupled” to indicate that two or moreelements are in direct physical or electrical contact. The term“coupled,” however, may also mean that two or more elements are not indirect contact with each other, but yet still co-operate or interactwith each other. The embodiments are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and B is false (or not present), A is false (or notpresent) and B is true (or present), and both A and B are true (orpresent).

In addition, use of the “a” or “an” are employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the description. Thisdescription, and the claims that follow, should be read to include oneor at least one and the singular also includes the plural unless it isobvious that it is meant otherwise.

The patent claims at the end of this patent application are not intendedto be construed under 35 U.S.C. § 112(f) unless traditionalmeans-plus-function language is expressly recited, such as “means for”or “step for” language being explicitly recited in the claim(s).

1. A computer-implemented method for managing insurance records forpolicies for individuals, the method comprising: implementing aplurality of servers, each of the plurality of servers maintaining acopy of a distributed ledger; when an insurance policy is created for agiven individual, storing to the distributed ledger a transaction recordrepresenting the created insurance policy, including a policy number anda coverage amount for the created insurance policy, wherein storing thetransaction record includes: (i) generating, at a first server from theplurality of servers, the transaction record representing the createdinsurance policy; (ii) proposing the transaction record to one or moreother servers from the plurality of servers; (iii) performing, via theplurality of servers, a consensus analysis of the transaction recordutilizing a consensus mechanism; and (iv) when the consensus analysisindicates that the plurality of servers have formed a consensus, storingthe transaction record at the distributed ledger by storing thetransaction record to each copy of the distributed ledger at theplurality of servers; receiving, at the plurality of servers, anelectronic message including a request for a verification regardingwhether or not an individual of interest is insured; responding, via theplurality of servers, to the request for the verification by: (i)determining that the individual of interest is the given individual and(ii) detecting that the distributed ledger includes one or moretransaction records representing one or more insurance policies for thegiven individual; and responding to detecting that the distributedledger includes one or more transaction records representing one or moreinsurance policies for the given individual, including: (a) generatingthe verification by retrieving from the distributed ledger all of theone or more transaction records, including the transaction recordrepresenting the created insurance policy, and (b) generating a summaryof all of the one or more insurance policies represented by theretrieved one or more transaction records, wherein the summary includesthe policy number for the created insurance policy.
 2. The method ofclaim 1, wherein storing the transaction record at the distributedledger comprises: storing the transaction to a block.
 3. The method ofclaim 2, wherein performing the consensus analysis comprises generatinga hash value for the transaction, and utilizing the hash value for thetransaction to generate a hash value for the block.
 4. The method ofclaim 1, wherein the consensus mechanism is: a proof of work mechanism,a proof of stake mechanism, or a proof of activity mechanism.
 5. Themethod of claim 1, wherein the consensus mechanism is: a proof of burnmechanism, a proof of capacity mechanism, or a proof of elapsed timemechanism.
 6. The method of claim 1, wherein the transaction recordincludes data representing: an identity of the given individual.
 7. Themethod of claim 1, further including verifying that a requestor thatsubmitted the request for the verification is authorized, wherein theverification is only generated when requestor is authorized.
 8. Themethod of claim 7, further comprising receiving from the givenindividual a list of authorized parties; wherein verifying that therequestor is authorized includes verifying that the requestor is on thelist of authorized parties.
 9. The method of claim 7, further comprisingreceiving from an insurance company a list of authorized parties;wherein verifying that the requestor is authorized includes verifyingthat the requestor is on the list of authorized parties.
 10. (canceled)11. A system for managing insurance records for a policies forindividuals, the system comprising: a plurality of servers maintaining adistributed ledger for managing insurance records, wherein each of theplurality of servers includes a memory storing: (A) a copy of thedistributed ledger, and (B) instructions that, when executed, cause therespective server to: (i) generate, at the respective server, atransaction record representing a created insurance policy for givenindividual, including a policy number and a coverage amount for thecreated insurance policy; wherein the plurality of servers areconfigured to: (A) store to the distributed ledger the transactionrecord representing the created insurance policy, wherein the pluralityof servers: (i) perform a consensus analysis of the transaction recordutilizing a consensus mechanism; and (ii) store the transaction recordat the distributed ledger when the consensus analysis indicates that theplurality of servers have formed a consensus by storing the transactionrecord to each copy of the distributed ledger at the plurality ofservers; (B) receive an electronic message including a request for averification regarding whether or not an individual of interest isinsured; (C) respond to the request for the verification by: (i)determining that the individual of interest is the given individual, and(ii) detecting that the distributed ledger includes one or moretransaction records representing one or more insurance policies for thegiven individual; and (D) respond to detecting that the distributedledger includes one or more transaction records representing one or moreinsurance policies for the given individual, including: (1) generate averification of insurance information for the individual of interest byretrieving from a copy of the distributed ledger all of the one or moretransaction records, including the transaction record representing thecreated insurance policy, and (2) generate a summary of all of the oneor more insurance policies represented by the retrieved one or moretransaction records, wherein the summary includes the policy number forthe created insurance policy.
 12. The system of claim 11, wherein theplurality of servers are configured to store the transaction record atthe distributed ledger by storing the transaction to a block.
 13. Thesystem of claim 12, wherein the plurality of servers are configured toperform the consensus analysis by generating a hash value for thetransaction and utilizing the hash value for the transaction to generatea hash value for the block.
 14. The system of claim 11, wherein theconsensus mechanism is: a proof of work mechanism, a proof of stakemechanism, or a proof of activity mechanism.
 15. The system of claim 11,wherein the consensus mechanism is: a proof of burn mechanism, a proofof capacity mechanism, or a proof of elapsed time mechanism.
 16. Thesystem of claim 11, wherein the transaction record includes datarepresenting: an identity of the given individual.
 17. The system ofclaim 11, wherein the plurality of servers are further configured toverify that a requestor that submitted the request for the verificationis authorized, wherein the verification is only generated when therequestor is authorized.
 18. The system of claim 17, wherein theplurality of servers are further configured to receive from the givenindividual a list of authorized parties; wherein the plurality ofservers are configured to verify that the requestor is authorized byverifying that the requestor is on the list of authorized parties. 19.The system of claim 17, wherein the plurality of servers are furtherconfigured to receive from an insurance company a list of authorizedparties; wherein the plurality of servers are further configured toverify that the requestor is authorized by verifying that the requestoris on the list of authorized parties.
 20. (canceled)